Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.55%. Comparing base (08ab7fb) to head (81c36cb).
Report is 76 commits behind head on main.

❗ There is a different number of reports uploaded between BASE (08ab7fb) and HEAD (81c36cb). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (08ab7fb)	HEAD (81c36cb)
	2	1

@@            Coverage Diff             @@
##             main     #431      +/-   ##
==========================================
- Coverage   85.06%   78.55%   -6.52%     
==========================================
  Files          19       31      +12     
  Lines        1346     2490    +1144     
==========================================
+ Hits         1145     1956     +811     
- Misses        125      445     +320     
- Partials       76       89      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I'm not sure I'm fully understanding the scenario described in the description. Are you talking about this watch?

It looks like that watch+handler adds items to the workqueue the owner of the secret (which is the CR), but does not check that the owner matches the label selector.

If I'm understanding correctly, another way to implement this would be to have a custom handler that:

• knows about the label selector
• Gets the owner CR from the informer cache
• only adds the request to the workqueue if the owner CR matches the label selector

This would ensure the request never even makes it into the workqueue and would avoid unnecessary reconcile calls (which can mess with controller-runtime metrics and logging in a way that might be undesirable).

We had a similar thing in Rukpak (except based on a "provisionerClassName" match rather than a label selector): https://github.com/operator-framework/rukpak/blob/5ffcfff615566f3a1a482a5f6649cd3e07f2427f/pkg/util/util.go#L52-L108

@joelanford your idea sounds much more elegant. In an attempt to try and distribute the workload I asked @kurlov and he kindly agreed to take a look at implementing this in a week or so.

PR needs rebase.

@joelanford I have opened a separate PR #443.
But I decided to change the secret watch because there might be a potential bug. ATM running two reconcilers with the same GVK but different label selectors make all of them to reconcile each other CRs ignoring provided label selectors. If this is not a valid scenario then I will change the implementation to what you have suggested initially